BLUEPRINT

3 Дорожная карта эволюции версий

Глава 3: Дорожная карта эволюции версий

В данной главе определяется дорожная карта эволюции версий протокола CAP, устанавливается функциональный объём версии v1 и исключения, правила именования версий и стратегия совместимости, а также описывается процесс публикации от черновика до официальной версии. Дорожная карта версий обеспечивает чёткое руководство для итеративной разработки протокола и сотрудничества сообщества.

3.1 Функциональный объём версии v1

Версия v1 протокола CAP сосредоточена на создании полной базовой структуры управления полномочиями терминала и включает следующие 6 основных возможностей:

Офлайн-авторизация (Authorization_Descriptor): Основной механизм версии v1. Реализация полного управления жизненным циклом Authorization_Descriptor, включая выдачу, локальное хранение, проверку, отзыв и обновление. Терминал в офлайн-режиме может самостоятельно выполнять проверку авторизации с использованием локально хранящегося Authorization_Descriptor, обеспечивая базовую доступность Fay в среде без сети. Версия v1 реализует полную модель цепочки доверия и механизм локального списка отзыва.
Онлайн-билеты (Trusted_Ticket): Дополнительный механизм версии v1. Реализация возможностей выдачи авторизации в реальном времени и запроса статуса отзыва в сетевой среде, поддержка преобразования Trusted_Ticket в локальный формат Authorization_Descriptor, а также стратегия плавной деградации от онлайн к офлайн. Версия v1 обеспечивает согласованную работу онлайн-билетов и офлайн-авторизации.
Управление сеансами (Session lifecycle): Реализация полного управления жизненным циклом сеансов управления, охватывающего три этапа: создание, активный и завершение. Версия v1 поддерживает привязку Session к Terminal_Resource один к одному, реализует три способа завершения сеанса: активное освобождение, завершение по тайм-ауту и завершение по отзыву.
Стратегия передачи управления (Handover_Policy): Реализация возможности передачи управления между несколькими сторонами, охватывающая сценарии передачи между Fay, а также между Fay и пользователями-людьми. Версия v1 поддерживает три типа стратегий (скрипт правил приоритета, решение AI-модели в реальном времени, решение пользователя-человека), гарантирует атомарность процесса передачи и реализует механизм отката по тайм-ауту.
Обнаружение активности (Liveness_Detection): Реализация механизма обнаружения активности сеансов на основе сочетания постоянных соединений и heartbeat на уровне приложения. Версия v1 поддерживает логику двойного определения (одновременное выполнение условий разрыва постоянного соединения и тайм-аута heartbeat), настраиваемые интервалы heartbeat и пороги тайм-аута, а также автоматическое завершение недействительных сеансов и освобождение ресурсов.
Режимы доступа к ресурсам (Resource_Access_Mode): Реализация многоуровневого управления доступом к ресурсам по типу операции, поддержка четырёх режимов доступа: read, write, execute, configure. Версия v1 реализует полную модель блокировки чтения-записи, поддерживая параллельный доступ нескольких сторон в режиме read и эксклюзивное управление в режимах write, execute и configure.

Указанные 6 основных возможностей составляют полный функциональный набор версии v1, обеспечивая базовую структуру управления полномочиями для безопасного принятия интеллектуальными агентами управления терминалами в экосистеме iFay.

3.2 Функции, явно исключённые из v1

Следующие функции явно не включены в версию v1 и отмечены как кандидаты для будущих версий:

Исключённая функция	Описание	Версия-кандидат
Миграция сеансов между терминалами	Перенос активного Session с одного терминала на другой с сохранением непрерывности состояния сеанса	v2+
Совместная авторизация нескольких терминалов	Механизм синхронизации состояния авторизации и совместной проверки между несколькими терминалами	v2+
Цепочка делегирования авторизации (Delegation Chain)	Механизм каскадной авторизации, при котором Fay делегирует часть полученной авторизации другим Fay	v2+
Детализированный контроль доступа к ресурсам (ABAC)	Стратегия контроля доступа на основе атрибутов, поддерживающая более сложные условия доступа к ресурсам	v2+
Стандартизированный формат журнала аудита	Унифицированный формат вывода журнала аудита (Audit_Logger) и спецификация интерфейса запросов	v2+
Спецификация шифрования передачи сообщений протокола	Стандартизированное определение способа шифрования сообщений протокола CAP на транспортном уровне сети и процесса согласования ключей	v2+
Распределённый консенсус отзыва офлайн-авторизации	Механизм достижения консенсуса о статусе отзыва между несколькими терминалами в офлайн-среде	v3+
Динамическое повышение разрешений (в рамках Session)	Динамическое повышение разрешений доступа в течение жизненного цикла активного Session без создания нового Session	v3+

Версия v1 следует принципу «сначала создать основу, затем расширять возможности», приоритетно обеспечивая полноту и стабильность 6 основных возможностей, оставляя расширенные функции для последующих итераций версий.

3.3 Правила именования версий и стратегия совместимости

Правила именования версий

Протокол CAP использует формат семантического версионирования (Semantic Versioning): MAJOR.MINOR.PATCH

MAJOR (основная версия): Увеличивается при несовместимых существенных изменениях протокола. Например, структурная перестройка формата основных сообщений, фундаментальное изменение процесса проверки авторизации. Изменение основной версии означает, что существующие реализации требуют адаптации
MINOR (дополнительная версия): Увеличивается при добавлении обратно совместимых функций или возможностей. Например, добавление нового режима доступа к ресурсам, расширение типов стратегий Handover_Policy. Изменение дополнительной версии не влияет на нормальную работу существующих реализаций
PATCH (версия исправления): Увеличивается при обратно совместимых исправлениях ошибок или уточнениях документации. Например, исправление неоднозначных описаний в документации спецификации, дополнение описания обработки граничных случаев

Черновые версии используют идентификатор draft без номера версии. Черновые версии не гарантируют совместимость и могут подвергаться разрушающим изменениям в любое время.

Примеры номеров официально выпущенных версий: 1.0.0, 1.1.0, 1.1.1, 2.0.0

Стратегия совместимости

Стратегия совместимости протокола CAP следует следующим принципам:

Обратная совместимость в рамках одной основной версии: В рамках одной MAJOR версии реализация новой версии протокола должна быть способна обрабатывать сообщения протокола старой версии. Например, терминал, реализующий v1.2.0, должен быть способен обрабатывать Authorization_Descriptor формата v1.0.0
Отсутствие гарантии совместимости между основными версиями: Обратная совместимость между различными MAJOR версиями не гарантируется. При увеличении основной версии спецификация протокола явно перечисляет все разрушающие изменения и руководство по миграции
Согласование версий Schema и протокола: Каждая версия протокола соответствует версии Schema; файлы Schema хранятся в каталоге, названном по номеру версии протокола (например, schema/2025-10-25/), обеспечивая чёткую и отслеживаемую связь версий
Объявление минимальной поддерживаемой версии: Реализация протокола может объявить минимальную поддерживаемую версию протокола; сообщения протокола ниже этой версии будут отклонены

3.4 Процесс публикации от черновика до официальной версии

Публикация протокола CAP от черновика до официальной версии следует следующему процессу:

Этап первый: Черновик (Draft)

Спецификация протокола и определения Schema хранятся в каталоге draft/ (например, schema/draft/, specification/draft/)
На этапе черновика допускаются частые разрушающие изменения без гарантии совместимости
Содержимое черновика принимает обратную связь и рецензирование от сообщества, непрерывно итеративно улучшаясь
Документация и Schema на этапе черновика могут обновляться в любое время без соблюдения правил увеличения номера версии

Этап второй: Кандидат на выпуск (Release Candidate)

Когда содержимое черновика стабилизируется, начинается этап кандидата на выпуск
Версии кандидата на выпуск используют суффикс -rc.N (например, 1.0.0-rc.1)
На этапе кандидата на выпуск принимаются только исправления ошибок и уточнения документации, новые функции не принимаются
Версии кандидата на выпуск должны пройти полную тестовую верификацию, включая проверку Schema, проверку структурной эквивалентности многоязычной документации и тестирование свойств

Этап третий: Официальный выпуск (Release)

После достаточной верификации версии кандидата на выпуск суффикс -rc.N удаляется, и версия становится официальной
Спецификация протокола и определения Schema официальной версии копируются из каталога draft/ в каталог, названный по дате версии (например, schema/2025-10-25/)
После официального выпуска спецификация протокола и определения Schema данной версии больше не изменяются (immutable); любые изменения публикуются через новую версию
При официальном выпуске документация архитектурного плана и спецификации протокола на всех 9 языках должна быть синхронно завершена и пройти верификацию структурной эквивалентности

Этап четвёртый: Сопровождение (Maintenance)

После официального выпуска версия переходит в этап сопровождения, принимая только исправления уровня PATCH
При выпуске новой MAJOR или MINOR версии старая версия переходит в период ограниченного сопровождения и в конечном итоге помечается как устаревшая (deprecated)
Документация и определения Schema устаревших версий сохраняются в репозитории для исторической справки, но больше не принимают обновлений